MediaLiveのChannelがRunningのままWorkflowを削除してChannelを止め忘れてしまった話

はじめに

清水です。ブロードキャストグレードのライブ動画処理サービスであるAWS Elemental MediaLive、検証用途などで使用する上で注意しなければいけないことにChannelリソースの止め忘れというものがあります。

個人的に、2017年11月のMediaLiveリリース直後からこの止め忘れについては注意していていたのですが、先日ひさしぶりに長時間の止め忘れをしてしまいました。この事象の振り返りと、取りうる対策などをまとめておこうと思います。

MediaLiveのChannelリソースと止め忘れ

入出力など様々な設定がまとめられておりMediaLiveの動作の中心ともいえるChannelリソース、Running状態で入出力動作を行います。そしてこのRunningの状態の間、入出力に関する料金が発生します。24/7で稼働しているChannelであればよいのですが、一定時間のみの稼働を想定しているCahnnelの場合、利用を終えたあとこのChannelリソースをStopしてIdle状態にしておかないと想定外の高額な料金が発生してしまいます。（なおIdle状態のリソースにも、Runnig状態と比べると低額ですが料金が発生します。）

なお、AWSでMediaLiveと類似するサービスとしてAmazon Interactive Video Service (Amazon IVS)があります。Amazon IVSではChannelのStart/Stopの操作は不要で、RTMPのingestがあれば自動的に入出力が開始されライブストリーミングがはじまります。

なぜMediaLiveではややもするとリソースの止め忘れで意図しない料金が発生してしまうような、Start/Stopの操作を必要としているのでしょうか。それはMediaLiveが単純にRTMP ingestを受けてライブ配信を行うのみならず、RTMP ingest中断時のフェイルオーバーやMP4ファイルなどを用いたライブソース以外を含めたスケジューリング配信などに対応したビデオ処理サービスであるためです。RTMP ingestがない状態でも、ChannelをStopしない限りライブビデオ処理自体は進行する、というわけですね。MediaLiveとAmazon IVSの思想の違いのようなものがこういったところに現れているのかと思います。

ひさしぶりにChannelリソースを止め忘れてしまった！

さて、そんなMediaLiveのChannelリソースの止め忘れ、個人的にここ最近はめっきりやらなくなっていました。止め忘れをしないように注意していたこともありますが、MediaLiveでWorkflow wizardが利用可能になりリソースの作成ならびに削除が簡単になったことも一因かと思います。検証のリソースについては、基本的に検証のタイミングでWorkflow wizardを使ってリソースを作成、検証が終わればWorkflowごとまるっと削除してしまう、というぐあいで使っていました。

そして先日も、以下ブログの執筆の際、Workflowを用いてリソースを作成しました。

• AWS Elemental MediaLiveで映像へのタイムコードの焼き付けをサポートしました！?burn-in? | DevelopersIO

しかも動作確認のため、Outputを3つ設定していたのですね。止め忘れることも知らずに。

検証を行っていたのは2023/01/27、金曜日です。このブログ執筆後、いつものようにサクッとMediaLiveリソースは削除してしまおうと、Workflow画面でで[Delete workflow]ボタンを押下しました。そう、[Delete workflow]ボタンは確実に押したのです、これはきちんと覚えていました。

そして楽しい週末を終え、週明けにふとMediaLiveのChannelリソースのことが頭をよぎりました。「まぁ削除ボタンはしっかり押したしな、とはいえいちおう確認だけしておくか」、とMediaLiveのマネジメントコンソールに進みます、、すると、、

そこにはRunning状態のChannelがいました。$100を優に超えるAWS利用費とともに、、。

Channelリソース止め忘れの状況を振り返る ~ 原因はWorkflow!?

ひさしぶりにやらかしてしまったことにショックを受けつつ、ひとまずChannelリソースをStopします。たしかに[Delete workflow]ボタンは押したはずなんだけど、と、Workflow画面のほうを確認してみました。するとなんと、リソース削除に失敗、Delete failedな状態でした。

MediaPackageとCloudFrontのリソースはDELETE_COMPLETEで削除されているけど、MediaLiveのリソースであるInputとChannelはDELETE_FAILEDで残ったまま、そしてMediaLiveのChannelは停止されていない、という状況です。

[Delete workflow]したのだからMediaLiveのInput/Channelリソースも消えるものだと思っていたのですが、MediaLive ChannelがRunning状態（StopされIdleでない状態）であればMediaLiveのリソースは消えない、ということだったのでしょうか。たしかに挙動としてはおかしくはない（Running状態であれば先にStopを求めるべき）のですが、ほかリソースが消えてしまっていることから少し釈然としません。

先ほどのブログの検証環境をもう一度確認して振り返ってみます。以下のような操作を行っていました。

1. Workflow wizardでリソース一式を作成
   • Channel class: SINGLE_PIPELINE
   • Input type: RTMP (push)
   • Output: MediaPackage
     • Renditions: 1080p30, 720p30, 480p30
2. OutputのいくつかにTimecode burninの設定
3. ChannelをStartさせて焼き付けられたタイムコードの確認
4. ChannelをStopして各Outputでフレームレートをノンドロップフレームに変更（29.97fpsから30fpsへ）
5. 再度ChannelをStartさせてノンドロップフレームのタイムコードの焼き付けを確認
6. [Delete workflow]ボタンを押下

Channelの設定、例えばTimecode burninやフレームレートを変更したためにMediaLive Channelが削除できなくなってしまった、ということも考えました。なにはともあれ、上記ブログと同等の設定でもう一度workflowを作成し、動作を検証してみます。ただしOutputは720p30の1つのみとしました。

さて、ブログエントリと同じ手順でOutput設定、Timecode burningの設定を変更してChannelをStartさせます。フレームレートの変更をは行っていませんが、このまま[Delete workflow]してみましょう。と、workflow詳細画面を確認してみますが、以下のように[Delete workflow]は非アクティブでボタンできない状態になっています。

ただし、この画面に遷移するまでに「おや!?」と思うことがありました。Worfklowの詳細画面に遷移した直後、まずChannel stateはPendingと表示されます。少し時間が経ったあと、ChannelのStateを反映した状態（ここではRunning）となります。状況としてはChannelのStateを読み取っているロード時間のようなものと推測されます。そしてこの反映までの時間、[Delete workflow]ボタンがアクティブになっているのです。またこの状況下で実際に[Delete workflow]ボタンの押下が可能でした。以下、動画でご確認ください。

動画中でも確認していますが、この詳細画面に遷移した直後のタイミングで[Delete workflow]ボタンを押下すると、workflowの削除処理が実施されます。しかしRunnig状態であるMediaLiveリソースはそのまま残り、workflow内のMediaPackageとCloudFrontのリソースのみ削除される、という先ほどと同じ状態が再現できました。

つまり止め忘れについては、workflow詳細画面で本来であれば非アクティブになっているボタンが画面遷移のわずかなタイミングでアクティブ化されており、そのタイミングで[Delete workflow]ボタンを押下してしまった。MediaLive ChannelとしてはRunning状態のときの削除はできず、Runningのままとなった。（そして私がMediaLive Channelが削除されていると思い込み、止め忘れとなってしまった。）という事象だっと結論付けられるかと思います。（たしかに慌てて、画面のロードを待たずにそそくさと[Delete workflow]ボタンを押下した記憶があります。。）

フィードバックの送信と同様の事象が起こりうる可能性の確認

Channelの止め忘れはマネジメントコンソールのworkflow画面、詳細ページへの遷移のタイミングの意図しない動作が起因していた、ということが確認できました。もちろん、[Delete workflow]の操作後、リソース削除の状況をきちんと確認すれば止め忘れにはならなかったわけですが。それでも、画面遷移の直後にWorkflowがRunningであるにもかかわらず[Delete workflow]が押下できるのはいただけないよな、とも思わなくもありません。

こんなときにはAWSへのフィードバックを行いましょう。開いているMediaLiveのマネジメントコンソール、左下のフィードバックボタンから進みます。

必要事項を記入して、フィードバックを送信します。

さて、それでは今回の事象について、仮にマネジメントコンソールにフィードバックが反映され、workflow詳細画面への遷移の際に[Delete workflow]ボタンが非アクティブになれば防げたのでしょうか。ここでWorkflowの実態がCloudFormation Stackであることを考えてみましょう。（MediaLiveのWorkflow Wizardで作成されるリソースをカスタマイズ！ ~MediaStoreのCORSとCDN認証の設定を入れてみよう~ | DevelopersIO）MediaLiveのマネジメントコンソール上ではChannelのStateを確認していますが、CloudFormationのマネジメントコンソール上では確認を行いそうにありません。（例えばEC2の起動状態やTermination protectionなどのチェックはしませんよね。）MediaLive Workflowの実態であるStackをChannelのRunning中に削除してしまうことでも同様の事象は再現できるかと思いました。

実際にやってみましょう。先ほどと同じ条件でworkflowを作成し、ChannelのRunning中にCloudFormationの画面からDelete Stackしてみます。

CloudFormation Stackの削除の結果はDELETE_FAILEDとなりました。MediaLiveのマネジメントコンソール、画面切り替えのわずかなタイミングで[Delete workflow]をしたときと同様、Running状態のMediaLiveリソースのみ残り、MediaPackageとCloudFrontのリソースは削除済みとなっている、という結果です。

もしMediaLiveマネジメントコンソール側でRunning状態のWorkflowのDeleteできない操作が徹底されても、CloudFormationマネジメントコンソール側からはこのような操作ができてしまう点、留意しておきましょう。なお常時稼働を前提としたWorkflowなどで、Channelの状態（Runningか否か）いかんによらずCloudFormationマネジメントコンソールやAPIからの削除を防止したいという場合、Stackの削除保護機能などが検討できるかと思います。（[新機能] CloudFormationのStackに削除保護が設定可能になりました | DevelopersIO）

再発防止のための対策

検証時の手順の再現から今回のChannelの止め忘れまでの操作、そして同様の事象がほかにも起こりうることを確認してきました。ここではどうすれば今回の事象のようなケースでChannelの止め忘れを防ぐ、もしくは短時間で気づくことができるのかについてまとめてみたいと思います。

操作結果をしっかりと確認する！

そもそも今回のChannelリソースの止め忘れ、削除操作をしたあとの確認が漏れていたことが直接的な原因だと考えています。削除操作後、削除が完了したであろうタイミングで操作（削除）が成功しているか確認していれば、今回の事象に迅速に気がつくことができ、長時間のリソースの止め忘れを防ぐことができたでしょう。削除に限らずですが、やはり重要なのは操作結果をしっかりと確認することにつきるなと改めて思いました。

料金アラームのさらなる活用

AWSで不意な料金の発生を防ぐ方法のひとつに料金アラームを設定し、一定金額を超えたら通知を行うという方法があります。今回対象となったアカウントでも料金アラームは設定していたのですが、$50を超えたら通知という1つのみの設定でした。そして今回の事象が発生する少し前のタイミングにアラームが発砲、月額$50を超えていると認識しつつそれ以上のアラームは通知されないという状況でした。

アラームのしきい値を何段階化にわけ、例えば$50の次に$100、さらに$200で通知を行うなどとすれば今回の事象、想定外の料金が発生してしまったというのは回避できたかもしれません。または1日ごとに一定の金額を超えたら通知するといったことでも、より迅速に事象に気がつくことができたかと考えます。

MediaLiveのリソース監視

料金アラームでChannelの止め忘れに気がつく、というのもひとつの方法なのですが、通知のタイミングなどで実際に気がつくまでに時間がかかってしまう可能性もあるかと考えます。より迅速にChannelの止め忘れに気づくためには、MediaLiveのリソース監視を行う方法も有用かと考えます。

例えば1時間に1回など定期的にMediaLiveリソースを監視、Runnig状態のChannelがあれば通知を行うといった仕組みが検討できるかと思いました。24/7で本番稼働しているChannelの場合にはRunning状態でなくなったときにアラート通知を行うべきですが、検証環境のChannelであり連続稼働しているのが本来の状態でないのであればこのようなリソース監視も行えそうですよね。AWSアカウント内すべてのChannelが検証環境ということであればアカウント全体のChannelを監視し、もし混在しているような場合はChannelリソースへのタグ付けなどでの監視の絞り込みができるかと考えています。いずれにせよ（料金アラーム含めて）、通知をきちんと確認して次のアクションにつなげることが重要ですね。

まとめ

ひさしぶりにやってしまった！AWS Elemental MediaLiveのChannelリソースの止め忘れについて、状況の振り返りと再発防止についてまとめてみました。マネジメントコンソールの意図していない動作が発端となったとはいえ、削除操作実施後のリソースの状態確認をしていれば防げたことだったかなと思います。再発防止策についてもしっかりと実践し、こんどこそ止め忘れをしないようにしたいと思いました。